Archive system and method for copy controlled storage devices

ABSTRACT

A data archiving system and method is described. A storage device ( 10 ) is arranged to communicate with an archival device ( 40 ) and to upload a stored file ( 30 ) thereto. The storage device ( 10 ) is arranged to generate a file encryption key and encrypt the file with the file encryption key upon upload to the archival device ( 40 ). The file encryption key can be regenerated by the storage device ( 10 ) upon presentation of the encrypted file.

The present invention relates to an archive system for copy controlledstorage devices and is particularly applicable to the secure transfer ofMP3 players and the like.

The digital convergence of PCs and consumer electronics (CE) devicesholds enormous promise for the industry. It also poses immediatechallenges. The mere prospect of hundreds of millions of dollars incopyrighted content being pirated is enough to limit issue of content inthe digital domain. Indeed, some companies have developed technologiesthat prevent content being transferred to the digital domain. Examplesinclude CDs designed to be unreadable in CD-ROM drives whilst stillbeing playable in HiFis to prevent the ripping of the audio data onthem. Various systems exist which create errors on the CD, which arecorrected in HiFi CD players, but make the disk unreadable in CD-ROMdrives.

Other than creating ill-feeling with users, one potential problem isthat these systems restrict people from recording music for private,noncommercial uses and may contravene laws allowing home recordal and/ortransfer of the data to another medium.

In order to address this, many systems have been suggested that providelimited copying/movement of digital content data to the legal owner.

Some existing suggestions seek to store data encrypted on a device, sothat only the originator would be able to retrieve the file. However,for storage devices required to output data in real time, the encryptionoverhead can be problematic. Particular problems with encrypted filesare encountered with so-called trick-play Dumping forwards/backwardswhilst playing).

In order to address these and other issues, the Digital TransmissionLicensing Authority (DTLA) have proposed a content protection system forthe IEEE 1394 bus specification dealing with isochronous transmissions.The system provides content protection so that copyrighted and othervaluable content can be protected from unauthorized copying. The systemspecification is called the Digital Transmission Control Protocol (DTCP)and is incorporated herein by reference.

Providing secure isochronous communications is important because allnodes on the network have access to the data being transmitted and socould take additional copies. In contrast to asynchronous transmissionswhere the identity (or at least some identifier) of the transmitter andreceiver is known by both parties, implementations of isochronoustransmissions typically take the form of a broadcast where identity ofthe sink (receiving) device may not necessarily be known by the source(data providing) device.

Content data is typically transmitted over IEEE 1394 bus as isochronoustransmissions whilst control data is transmitted using asynchronouscontrol packets. In order to provide the necessary content protection,the DTCP requires that isochronous transmissions are encrypted using asymmetric cipher system during transmission.

In a DTCP system, when accessing an isochronous transmission on the IEEE1394 bus, a sink device (the recipient of the data) first authenticateswith the source device (the holder of the data). During authentication,relevant encryption/decryption keys are obtained/agreed so that the sinkdevice can decode the isochronous transmission upon receipt.

A particular benefit of this system is that encryption occurs at thelink layer. Content is therefore available unencrypted above the linklayer, making application functions such as trick play and searchingmuch easier than if the data was encrypted.

A copy control system is also incorporated. Content owners can specifyhow their content can be used (“copy-once,” “copy-never,” etc.). Thisinformation is embedded within the content as copy control information(CCI) and communicated within isochronous transmissions. Onwardtransmission of content is limited by the IEEE 1394 bus and IEEE 1394devices in dependence on CCI status.

The link-layer solution encrypts the link between the two devices anduses embedded copy-control-information (CCI) from the data to determinewhether the data needs to be encrypted or indeed can even betransmitted. Data at each end is stored decrypted with the CCI beingstored with the data. In this way, communications between devices aresecure.

One problem with copy control mechanisms is that they are generally poorat, or lack, backup systems. For example, a “copy never” or“copy-no-more” data file under the IEEE 1394 system cannot betransferred from the storage device/medium holding it. In the event thatthe media or device is stolen, lost or fails, the data file is lost too.

The concepts of copy control limitation of content data and that ofarchival have to date conflicted. On one hand, a user wishes to be ableto back-up content data in case the device is lost, stolen etc. On theother, the content provider wishes to limiVprevent movement and copyingof content data to prevent copyright theft. Another problem with storagedevices is that they can only hold a limited amount of content data—oncethat amount is reached, existing content data must be overwritten inorder to introduce new content data to the device. Where copy control isenforced, content data that may have been purchased would have to beirretrievably overwritten to allow new content data to be stored. Thisis seen as a negative factor by the purchaser of such devices who wouldnot wish to purchase content data each time they wished to copy it ontoa storage device.

According to one aspect of the present invention, there is provided adata archiving system for a storage device arranged to communicate withan archival device and to upload a file thereto, wherein the storagedevice is arranged to generate a file encryption key and encrypt thefile with the file encryption key upon upload to the archival device,the file encryption key being regeneratable by the storage device uponpresentation of the encrypted file.

Data files are encrypted during archival and only the originating,“owner”, device is able to gain access to them in a decrypted state. Inone embodiment, this is achieved by embedding part of the seed necessaryto generate a decryption key in a header to the encrypted file. Only theowner device has remaining part allowing the file to be decrypted. Toretrieve any encrypted files previously stored, the device recreates anencryption key based on a shared seed that is split between the headerof the encrypted file and the device itself. This shared seed is usedduring the encryption process and is then stored in the storage deviceor at least partly in the file itself.

The storage device may include a private encryption key, the fileencryption key being generated in dependence on a randomly generatednumber and the private encryption key, wherein the randomly generatednumber is stored in a header to the file upon uploading.

The storage device may include a private encryption key and a fileencryption key database, the file encryption key being generated independence on the private encryption key, wherein data necessary togenerate a decryption key to decrypt the encrypted file is written tothe file encryption key database upon uploading. Data to match theencrypted file to the data necessary to generate a decryption key may bewritten to the encryption key database upon uploading.

The storage device may include a file encryption key database, whereinthe file encryption key is written to the file encryption key databaseupon uploading. An identifier may be written to the file and to the fileencryption key database upon uploading to associate the file encryptionkey with the encrypted file.

According to another aspect of the present invention, there is provideda data archiving method comprising:

generating a file encryption key;

encrypting a file with the file encryption key; and, uploading theencrypted file to an archival device;

regenerating the file encryption key upon download of the encryptedfile; and,

decrypting the file with the regenerated file encryption key.

The step of generating the file encryption key may comprise generatingthe file encryption key in dependence on a randomly generated number anda private encryption key and storing the randomly generated number in aheader to the file, wherein the step of regenerating the file encryptionkey comprises the step of obtaining the randomly generated number fromthe header to the file and regenerating the file encryption key independence on a randomly generated number and the private encryptionkey.

The method may further comprise the step of storing data necessary toregenerate the file encryption key in a file encryption key database.

The method may further comprise the step of writing data to the fileencryption key database for matching the encrypted file to the storeddata necessary to regenerate the file encryption key.

The method may further comprise the steps of writing an identifier to aheader of the file, the identifier comprising the data for matching theencrypted file to the stored data.

An example of the present invention will now be described in detail,with reference to the accompanying drawings in which:

FIG. 1 is a schematic diagram of a data archiving system according to anembodiment of the present invention;

FIG. 2 illustrates an embodiment of a system for generating andregenerating the split encryption key;

FIG. 3 illustrates another embodiment of a system for generating andregenerating the split encryption key;

FIG. 4 is a schematic diagram of an asynchronous communication systemsuitable for supporting the embodiment of FIG. 2 or 3;

FIG. 5 is a schematic diagram of the owner device of FIG. 4; and, FIG. 6is a schematic diagram of the format of an asynchronous packet extendedfor use in an embodiment of the present invention.

FIG. 1 is a schematic diagram of a data archiving system according to anembodiment of the present invention.

A storage device 10 includes a data storage medium 20 for holdingcontent data files 30. Files are selectively transferred or copied fromthe storage device 10, referred to as an owner device, on demand to anarchival device 40 for archival or storage.

When a file is transferred or copied, it is encrypted by the ownerstorage device 10. The archival device 40 stores the file in encryptedform and allows it to be freely copied. The decryption key is stored insuch a manner that it is derivable only by the owner device.

One embodiment of a system for generating and regenerating the splitencryption key is illustrated in FIG. 2.

Archival is initiated upon receipt by owner device 10 of an appropriatecommand from archival device 40. An encryption/decryption key 100 isgenerated by a content key generator 110 in the owner device 10 using arandom number 120 generated by a random number generator 125 inconjunction with a private key 130 of the owner device 10. The contentdata file 30 is encrypted using the encryption/decryption key 100 andthe random number 120 is then stored in a header 150 to the encryptedfile 30′. The encrypted file 30′ is then transmitted to the archivaldevice 40 for storage, recordal to another storage medium, onwardtransmission or any other use envisaged by the user.

The private key 130 is unique to the owner device 10. Therefore, even ifa third party obtained the encrypted file 30′ and extracted the randomnumber 120 from the header 150, the encryption/decryption key could notbe regenerated and thus the unencrypted content data file 30 could notbe accessed.

Should it be desired to restore the encrypted file 30′ to the ownerdevice 10, the archival device 40 (or any other connected device)transmits the encrypted file 30′ with an appropriate command to theowner device 10. The command instructs the owner device 10 to restorethe associated file. Upon receipt of the encrypted file 30′, the ownerdevice obtains the random number 120 from the header 150 and combinesthis with its private key 130 in the content key generator 110 toregenerate the encryption/decryption key 100. The content data file 30can then be decrypted and stored in the data storage medium 20 forsubsequent access.

If the encrypted file 30′ was downloaded onto another storage device,the combination of that storage device's private key and the randomnumber 120 from the header 150 would not result in the correctencryption/decryption key 100 and the unencrypted content data file 30could not be accessed.

The commands transmitted from the archival device 40 and the ownerdevice 10 may be made using the AV/C (Audio Visual Control) protocol.

The random number could be generated using one of the many knowntechniques for random number generation.

FIG. 3 illustrates another embodiment of a system for generating andregenerating the split encryption key.

As an alternative to storing the random number in a header to the file,the random number 120 is stored in a database 200 in the owner device10.

The encryption/decryption key 100 is generated by a content keygenerator 210 in the device 10. Data necessary to generate thedecryption key 100 is stored in the database 200 on the owner device 10along with file information so that appropriate data can be matched toencrypted files 30′ to enable decryption. The data and file informationis written to the database 200 at the time of encrypting the file 30′.

As in the previous embodiment, the encryption key used to encrypt thefile 30 is specific to the data file 30 and to the owner device 10 soother players would not be able to decrypt the file. However, it is thepairing of the encrypted file 30′ and the device 10 that identifies“ownership”. Authentication and Copy control information that wouldnormally be used to restrict transfer of copy controlled content doesnot need to be respected or inspected as the content data file 30 is notaccessible to any device other than the owner device 10. In this manner,the archival device could permit copying/transfer to any destinationincluding multiple downloads to any one device in the knowledge thatonly the legitimate owner can access the data file in an unencryptedform.

As an alternative to storing file information in the database 200, anidentifier (from which the encryption/decryption key is not derivable)may be stored in a header to the encrypted file 30′. The identifierwould also be stored with the random number 120 in the database 200.When presented with an encrypted file, the device 10 would obtain theidentifier and find the random number 120 in the database 200 with acorresponding identifier. Another variation that may be combined withthe above embodiments would be to store the whole encryption/decryptionkey 100 in the database 200 instead of the random number 120.

The encrypted version of the file 30′ held on the archival device 40 canthen be transferred elsewhere for safe keeping (such as burnt onto aCD/DVD) and may be copied freely.

FIG. 4 is a schematic diagram of an asynchronous communication systemsuitable for supporting the embodiment of FIG. 2 or 3.

The owner device 10, such as an MP3 player, is DTCP compliant andincludes a storage device 20 holding content data 30 such as MP3 encodedaudio files, MPEG multimedia files and the like. At the option of theauthor/originator, the content data may include copy control information(CCI) to limit distribution of the data. The source device 10 isconnected to an IEEE 1394 bus 50 via an IEEE 1394 bridge 15.

The archival device 40 includes an IEEE 1394 bridge 45 for connection tothe bus 30 and a storage device 46.

Taking as an example, the archival device 40 requests the owner device10 archives an MP3 file 30 to it. The owner device 10 includes an IEEE1394 chip as part of the DTCP system. An encryption key is generated ina manner as discussed above and the MP3 file 30 is then packetised andencrypted using the encryption system of the IEEE 1394 chip of thedevice 10. The random number or other identifier is added to theencrypted packets as a payload header and is illustrated below in moredetail. The encrypted packets are then transmitted asynchronously overthe bus 50. No authentication is necessary between the owner device 10and the archival device 40. Components of the DTCP system of the ownerdevice 10 are used to achieve the encryption.

At the archival device 40, the encrypted packets 30′ are received.However, the encrypted packets 30′ are not decrypted (and could not beas the archival device does not hold the decryption key). The packets30′ are stored in an encrypted form in the storage device 46.Preferably, the storage device 20 is configured so that it cannot beremoved and attached to a PC or other device for access of data. Forexample, this could be achieved mechanically by limiting interfaces onthe device to a single IEEE 1394 bridge. As this is the only point ofdata access to the storage device, authentication would have to takeplace to access data in an unencryptyed form and this could not becircumvented given that no IDE connection or the like is provided.Another alternative would be to use non-removable media or media such asNVRAM as the storage device 20.

DTCP is applied to the asynchronous transmissions in a similar manner tothat of isochronous transmissions. In order to apply the DTCP toasynchronous transmissions, the payload header also includes copycontrol and key change information. The packet structure including thepayload header is discussed in more detail below with reference to FIG.4. Where they are used, all other mechanisms are consistent with thecurrent DTCP specification, with the exception that encrypted packetsare transmitted asynchronously, not isochronously. It should however beemphasized that mechanisms such as authentication need not be used whenmerely archiving/restoring files.

New extension commands for the Audio Video device Command and Controlprotocol, specified for the IEEE 1394 bus and issued by the 1394 TradeAssociation (www.1394ta.orc) and incorporated herein by reference, areimplemented in order to allow encryption of asynchronous packets and theinitiation of archival/restoration.

Copy control information embedded within the data may be used toinitiate encryption when archiving. For example, the system may be setto force copy limited files to be archived whilst allowing free accessto copy freely files.

FIG. 5 is a schematic diagram of the owner device 10 of FIG. 4.

The device includes the storage device 20 connected via an encryptionmodule 250 to an asynchronous transmission buffer 260. The buffer 260communicates with the link layer 300 of the IEEE 1394 bridge of thedevice.

The device also includes an AKE system 270 in communication with acertificate store 280 for storing certificate(s) for the device. The AKEsystem 270 is connected to an AV/C control system 290 which in turncommunicates with the link layer 300 of the IEEE 1394 bridge of thedevice. The link layer 300 communicates with the physical layer 310which is connected to the physical IEEE 1394 bus 50.

The encryption module 250 includes a scramble/descramble unit 251, a keygenerator 252, a random number generator 253 and a private key store254. When a file 30 is to be transmitted from the storage device 20, thefile is packetised ready for transmission. The key generator 252 obtainsthe private key from the private key store 254 to generate an encryptionkey. This is combined with a random number from the random numbergenerator 253 to create a random encryption key. This is then passed tothe scramble/descramble unit 51 and used to encrypt the file 30. Therandom number or other identifier is then stored in a payload header.The packets are then passed to the buffer 260 for asynchronoustransmission.

As discussed above, data is decrypted upon receipt by obtaining therandom number or other identifier from the payload header of theencrypted packets. Using the obtained information, the random encryptionkey is regenerated. This is then used to decrypt the packets. Thedecrypted, depacketised file is then passed to the storage device 20unencrypted. In order to avoid the storage device being placed in anordinary PC and having its data read with no security preventing this,it is preferable that the only digital output for data on the storagedevice 20 is via the IEEE 1394 bridge and its illustrated componentsherein. It is important to note in such a scenario that the storagedevice 20 is prevented mechanically from being removed and interrogatedon a standard platform such as a PC. Any access to data in anunencrypted form on the storage device is via the bridge andconsequently utilizes the IEEE 1394 and DTCP protocol stack. Whereaccess is requested to data on the storage device, the Authenticationand Key Exchange (AKE) procedure, as described in the DTCPspecification, is instigated. Only authenticated, encryption enabled,devices would be able to gain access to this data in an unencryptedform, although for archival purposes, any device could instigate thearchival procedure. Inserting the storage device into a normal PC foruse as a standard IDE or SCSI hard disk would not be possible due tomechanical incompatibility, and connecting it to a standard IEEE1394device (without the DTCP encryption system) would result in failureof the AKE.

It will be apparent that encryption cannot occur at the link layer inasynchronous transmission like in isochronous transmissions. DTCPperforms the encryption in the link layer and is able to do this due tothe provision of Encryption Mode Indicator (EMI) and Odd/Even bits inthe isochronous packets. These respectively denote the CCI of the fileand when key changes occur. In asynchronous packets, these bits are notavailable and so have to be added on in the payload header. In order toachieve this, encryption takes place above the link layer.

FIG. 6 is a schematic diagram of the format of an asynchronous packetextended for use in an embodiment of the present invention.

The packet includes a standard header 400, a payload header 410 and apayload 420. The standard header 400 is consistent with headers used inDTCP and IEEE 1394 networks. The payload header 410 includes an EMIfield 411 used to convey CCI information, an odd/even field 412 used toconvey key change notification and the random number or other identifier413 used in regeneration of the encryption key. The values and usage ofthe EMI and Odd/Even bit are identical to the DTCP specification forisochronous packets. The payload 420 includes the encrypted packet ofdata.

Whilst the random number or other identifier have been discussed aboveas being included in the payload header of each packet, it is possiblethat it may only be included in the payload header of a predetermined(such as first or last) packet. In such a scenario, each packet wouldhave some identifier to designate the data stream it belongs to andthereby allowing correct depacketisation.

In addition, in the above embodiments, a file or data stream to bearchived are divided into individual packets and then encrypted. Thismeans that a number of encrypted packets are archived at the archivaldevice and all packets must be returned to the owner device to allowrestoration. Other embodiments are possible where the whole file or datastream is encrypted as a single entity and archived, allowing simplerfile handling and the like.

1. A data archiving system for a storage device (10) arranged tocommunicate with an archival device (40) and to upload a file (30)thereto, wherein the storage device (10) is arranged to generate a fileencryption key (100) and encrypt the file (30) with the file encryptionkey upon upload to the archival device (40), the file encryption key(100) being regeneratable by the storage device (10) upon presentationof the encrypted file (30′).
 2. A data archiving system according toclaim 1, wherein the storage device includes a private encryption key,the file encryption key (100) being generated in dependence on arandomly generated number (120) and the private encryption key, whereinthe randomly generated number (120) is stored in a header (410) to thefile (30) upon uploading.
 3. A data archiving system according to claim1, wherein the storage device (10) includes a private encryption key anda file encryption key database, the file encryption key (100) beinggenerated in dependence on the private encryption key, wherein datanecessary to generate a decryption key to decrypt the encrypted file(30′) is written to the file encryption key database upon uploading. 4.A data archiving system according to claim 3, wherein data to match theencrypted file (30′) to the data necessary to generate a decryption keyis written to the encryption key database upon uploading.
 5. A dataarchiving system according to claim 1, wherein the storage device (10)includes a file encryption key database, wherein the file encryption keyis written to the file encryption key database upon uploading.
 6. A dataarchiving system according to claim 5, wherein an identifier (413) iswritten to a header (410) of the file and to the file encryption keydatabase upon uploading to associate the file encryption key with theencrypted file.
 7. A data archiving method comprising: generating a fileencryption key; encrypting a file with the file encryption key; and,uploading the encrypted file to an archival device; regenerating thefile encryption key upon download of the encrypted file; and, decryptingthe file with the regenerated file encryption key.
 8. A method accordingto claim 7, wherein the step of generating the file encryption keycomprises generating the file encryption key in dependence on a randomlygenerated number and a private encryption key and storing the randomlygenerated number in a header to the file, wherein the step ofregenerating the file encryption key comprises the step of obtaining therandomly generated number from the header to the file and regeneratingthe file encryption key in dependence on a randomly generated number andthe private encryption key.
 9. A method according to claim 7, furthercomprising the step of storing data necessary to regenerate the fileencryption key in a file encryption key database.
 10. A method accordingto claim 9, further comprising the step of writing data to the fileencryption key database for matching the encrypted file to the storeddata necessary to regenerate the file encryption key.
 11. A methodaccording to claim 10, further comprising the steps of writing anidentifier to a header of the file, the identifier comprising the datafor matching the encrypted file to the stored data.
 12. A computerprogram comprising computer program code means for performing all of thesteps of any of claims 7 to 11 when said program is run on a computer.13. A computer program as claimed in claim 12 embodied on a computerreadable medium.